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Abstract 


This  paper  describes  the  sensor  and  weapon  models  that  will  be  used  to  simulate  a  red 
force  submarine  for  the  War-in-a-Box  (WIB)  exercise,  as  well  as  their  configurable 
parameters  and  the  necessary  data  agreements  amongst  all  simulation  components 
making  up  the  WIB  simulation.  It  proposes  Virtual  Maritime  Systems  Architecture 
(VMSA)  and  Real-Time  Platform  Reference  (RPR)  2.0  Federation  Object  Model 
(FOM)  objects  and  interactions  that  may  be  used  to  satisfy  the  communication 
requirements  of  the  submarine  simulation  with  other  WIB  federates.  It  is  provided  in 
response  to  a  call  for  information  from  the  WIB  team;  similar  information  has  been 
requested  from  the  other  WIB  participants.  The  resulting  collection  of  information 
will  be  used  to  develop  an  overall  RPR  2.0  FOM  implementation  plan  and  a  set  of  data 
agreements  for  the  exercise. 


Resume 


Le  present  document  decrit  les  modeles  de  capteur  et  d’arme  qui  seront  utilises  pour 
simuler  un  sous-marin  de  force  rouge  dans  un  exercice  War-in-a-Box  (WIB),  ainsi  que 
leurs  parametres  configurables  et  les  correspondances  de  donnees  necessaires  entre 
tous  les  elements  qui  prennent  part  a  la  simulation  WIB.  II  propose  des  objets  et 
interactions  du  modele  objet  de  federation  (FOM)  de  F  architecture  des  systemes 
virtuels  maritimes  (VMSA)  et  de  la  reference  plate-forme  en  temps  reel  RPR  2.0,  qui 
peuvent  etre  utilises  pour  satisfaire  aux  besoins  de  communications  de  la  simulation  de 
sous-marin  avec  d’autres  federes  WIB.  II  est  foumi  en  reponse  a  une  demande 
d’ information  provenant  de  l’equipe  WIB;  des  renseignements  semblables  ont 
egalement  ete  demandes  par  d’autres  participants  a  l’exercice  WIB.  La  collecte 
resultante  d’information  permettra  d’elaborer  un  plan  global  de  mise  en  oeuvre  FOM 
RPR  2.0  et  un  ensemble  de  correspondances  de  donnees  pour  l’exercice. 
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Executive  Summary 


Report  title 

Wentzell,  T.E.  and  Gillis,  Allan;  2005;  Proposed  Integration  of  VMSA  Submarine  for  WIB: 
RPR  FOM  2.0  Mapping  and  Data  Agreements;  DRDC  Atlantic  TM  2005-273;  Defence  R&D 
Canada  -  Atlantic;  Unclassified. 

Background 

Defence  Research  and  Development  Canada  -  Atlantic  (DRDC  Atlantic)  is  participating  in  a 
Canadian  Forces-wide  exercise  called  War-in-a-Box  (WIB)  which  aims  to  connect  military 
simulators  and  simulations  (federates)  located  across  the  country  using  the  High  Level 
Architecture  (HLA).  The  WIB  team  has  chosen  to  use  the  Real-Time  Platform  Reference 
(RPR)  Federation  Object  Model  (FOM)  version  2.0,  draft  17  for  the  exercise. 

The  Virtual  Combat  Systems  (VCS)  Group  is  contributing  a  red  force  submarine  to  the 
exercise,  simulated  by  a  Virtual  Maritime  Systems  Architecture  (VMSA)  federation  with  an 
object  model  that  differs  from  that  chosen  for  WIB.  In  order  for  the  submarine  to  participate 
in  the  overall  WIB  federation,  the  data  created  and  consumed  by  the  VMSA  simulation  must 
be  made  meaningful  to  the  rest  of  the  participating  federates,  and  vice  versa. 

A  similar  challenge  exists  for  all  federates.  Documentation  on  an  appropriate  RPR  2.0 
implementation  for  each  federate  was  requested  by  the  WIB  team. 

Principal  results 

This  paper  provides  descriptions  of  the  sensor  and  weapon  models  that  will  be  used  to 
simulate  the  enemy  submarine  and  identifies  configurable  parameters  and  required  data 
agreements.  Most  importantly,  it  proposes  VMSA  and  RPR  2.0  FOM  objects  and  interactions 
to  be  used  to  satisfy  the  communication  requirements  of  the  submarine  with  other  WIB 
federates. 

Significance  of  results 

The  information  within  this  document  is  input  into  a  much  larger  process.  Without  such 
information  from  each  federate,  it  would  not  be  possible  to  effectively  achieve 
communication  between  them.  Achieving  this  communication  is  a  critical  (probably  the  most 
critical)  component  of  the  WIB  exercise. 

Thinking  beyond  WIB,  identification  of  a  mapping  (even  on  this  limited  scale)  between  the 
VMSA  FOM  which  is  heavily  used  by  the  VCS  Group  and  the  RPR  2.0  FOM  which  is  a 
natural  choice  for  simulators/simulations  that  are  already  DIS  or  RPR  1.0  -  compliant, 
provides  opportunity  for  the  group  to  expand  the  capabilities  of  their  virtual  environment 
using  existing,  tried  and  true,  military  simulations. 
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Future  work 


The  next  step  of  the  integration  process  for  WIB  is  to  review  the  inputs  from  each  federate’s 
responsible  party  and  to  collectively  agree  on  how  the  RPR  2.0  FOM  will  be  used  to  support 
the  WIB  exercise. 
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Contexte 

Recherche  et  Developpement  pour  la  defense  Canada  -  Atlantique  (RDDC  Atlantique) 
participe  a  un  exercice  a  Pechelle  des  Forces  canadiennes  appele  War-in-a-Box  (WIB),  qui 
vise  a  relier  des  simulateurs  et  des  simulations  militaires  (federes)  repartis  a  travers  le  pays  au 
moyen  d’une  architecture  de  haut  niveau  (HFA).  F’equipe  WIB  a  decide  d’utiliser  le  modele 
objet  de  federation  (FOM)  de  la  reference  plate-forme  en  temps  reel  RPR,  version  2.0, 
ebauche  17,  pour  l’exercice. 

Fe  Groupe  des  systemes  de  combat  virtuel  (SCV)  fournit  un  sous-marin  de  force  rouge  pour 
l’exercice,  simule  par  une  federation  a  architecture  des  systemes  virtuels  maritimes  (VMSA) 
que  caracterise  un  modele  objet  different  de  celui  choisi  pour  WIB.  Afin  que  le  sous-marin 
puisse  s’integrer  a  la  federation  WIB  d’ ensemble,  il  importe  que  les  donnees  creees  et 
utilisees  par  la  simulation  VMSA  soient  significatives  pour  le  reste  des  federes  participants,  et 
vice  versa. 

Un  defi  semblable  existe  pour  tous  les  federes.  F’equipe  WIB  a  demande  de  la  documentation 
sur  une  mise  en  oeuvre  RPR  2.0  convenant  a  chaque  federe. 

Principaux  resultats 

Fe  present  document  decrit  les  modeles  de  capteur  et  d’arme  qui  serviront  a  simuler  le  sous- 
marin  ennemi  et  indique  les  parametres  configurables  ainsi  que  les  concordances  de  donnees 
requises.  Mais,  avant  tout,  il  propose  des  objets  et  interactions  de  FOM  VMSA  et  RPR  2.0 
permettant  de  repondre  aux  besoins  de  communications  du  sous-marin  avec  d’autres  federes 
WIB. 

Portee  des  resultats 

Conformation  incluse  dans  le  document  s’inscrit  dans  un  processus  beaucoup  plus  vaste.  Sans 
rinformation  provenant  de  chacun  des  federes,  il  ne  serait  pas  possible  d’etablir  des 
communications  efficaces  entre  eux.  F’etablissement  de  ces  communications  constitue  un 
aspect  crucial  (c’est  probablement  celui  qui  revet  la  plus  grande  importance)  de  l’exercice 
WIB. 

Au-dela  de  WIB,  la  determination  (meme  a  une  echelle  limitee)  d’un  mappage  entre  le  FOM 
VMSA,  qui  est  largement  utilise  par  le  Groupe  des  SCV,  et  le  FOM  RPR  2.0,  qui  constitue  un 
choix  naturel  pour  les  simulateurs/simulations  deja  conformes  a  DIS  ou  a  RPR  1.0,  donne  au 


DRDC  Atlantic  TM  2005-273 


V 


Groupe  l’occasion  d’elargir  la  capacite  de  l’environnement  virtuel  au  moyen  de  simulations 
militaires  existantes,  mises  a  l’essai  et  ayant  fait  leurs  preuves. 

Recherches  futures 

La  prochaine  etape  du  processus  d’ integration  de  WIB  consiste  a  examiner  la  contribution  du 
responsable  de  chaque  federe  et  a  s’ entendre  collectivement  sur  la  fagon  dont  le  FOM  RPR 
2.0  sera  utilise  a  l’appui  de  l’exercice  WIB. 


VI 
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1.  Background 


1.1  War-in-a-Box 

Defence  Research  and  Development  Canada  -  Atlantic  (DRDC  Atlantic)  is 
participating  in  a  Canadian  Forces-wide  exercise  called  War-in-a-Box  (WIB).  The 
aim  of  WIB  is  to  connect  military  simulators  and  simulations  which  are  located  across 
the  country  using  the  High  Level  Architecture  (HLA).  Through  a  competitive  bid 
process,  the  MAK  Run  Time  Infrastructure  (RTI)  was  selected  for  this  exercise.  The 
Real-Time  Platform  Reference  (RPR)  Federation  Object  Model  (FOM)  version  2.0, 
draft  17  [1]  was  chosen  by  WIB  team  members  to  define  the  information  and  format  of 
information  that  can  be  shared  amongst  the  simulation  federates.  By  mapping  the 
internal  data  object  models  of  each  simulation  into  this  format,  the  intention  is  that  the 
models  will  become  interoperable. 

1.2  VCS  Group’s  Simulation  Environment 

The  Virtual  Combat  Systems  (VCS)  Group  at  DRDC  Atlantic  has  been  developing 
their  HLA  expertise  over  the  past  few  years  and  has  a  collection  of  federates  which 
can  be  used  together  to  simulate  elements  of  a  maritime  environment.  These  federates 
however,  are  based  on  the  Virtual  Maritime  Systems  Architecture  (VMSA)  [2],  an 
application  and  extension  of  HLA  inclusive  of  its  own  FOM,  and  are  compiled  against 
the  Defense  Modeling  and  Simulation  Office  (DMSO)  RTI.  VMSA  takes  a 
component-based  approach  to  modelling  a  platform  (e.g.,  typical  federates  are  sonar, 
radar,  motion),  whereas  as  with  RPR,  modelling  tends  to  be  more  at  the  platform  level 
(e.g.,  typical  federates  are  ship(s),  sub(s),  etc.). 

1.3  VCS  Group’s  Contribution  to  WIB 

The  VCS  Group  is  contributing  a  red  force  submarine  to  the  WIB  exercise  which  will 
be  simulated  by  a  VMSA  federation  consisting  of  numerous  federates  (motion,  helm, 
passive  sonar,  Target  Motion  Analysis  (TMA),  Electronic  Support  Measures  (ESM), 
and  Horizon  Track  Management  Systems).  A  bridge  is  being  developed  [3]  that  will 
allow  this  federation  to  talk  to  the  WIB  RPR  2.0  federation.  To  all  other  WIB 
federates,  this  VMSA  federation  will  appear  simply  as  another  federate,  as  it  is 
through  a  single  RPR  2.0  federate  (a  component  of  the  bridge)  that  all  communication 
will  occur. 

1.4  The  Communication  Challenge 

Any  federate  that  subscribes  to  data  published  by  the  submarine  (VMSA  federation) 
will  receive  that  data.  Similarly,  the  submarine  requires  particular  data  from  the  RPR 
2.0  federation.  For  the  most  part,  it  is  the  data  sharing  between  the  VMSA  federation 
and  the  Joint  Semi- Automated  Forces  (JSAF)  constructive  simulation  that  is  of 
interest.  JSAF  will  be  modelling  the  ships  as  well  as  Maritime  Patrol  Aircraft  (MPA) 
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and  helicopters.  The  data  shared  with  other  RPR  2.0  federates  is  expected  to  be  a 
subset  of  the  data  shared  with  JSAF. 

While  at  first  this  problem  may  not  sound  so  complicated,  it  is  important  to  realize 
how  many  levels  of  ‘compatibility’  have  to  exist  in  order  to  achieve  effective 
communication,  even  between  JSAF  and  VMS  A.  First  of  all,  JSAF  has  its  own 
‘JSAF’  FOM  that  is  used  for  communication  between  multiple  copies  of  JSAF.  This 
FOM  must  be  mapped  to  the  RPR  2.0  FOM  via  JSAF’s  ‘Agile  FOM  Interface’  (AFI) 
layer.  Before  even  considering  the  FOM  level,  however,  there  is  the  issue  of  whether 
or  not  the  element  of  interest  is  even  part  of  both  models.  So,  for  any  given 
requirement,  the  following  questions  must  be  answered: 

•  Does  JSAF  model  it? 

•  Is  it  in  the  JSAF  FOM? 

•  Is  it  in  the  RPR  2.0  FOM? 

•  Is  it  in  the  VMSA  FOM? 

•  Is  there  a  VMSA  federate  which  models  it? 

Answering  no  to  any  of  these  questions  has  the  potential  to  be  a  ‘show-stopper’,  or  at 
least  to  require  creative  work-arounds  that  take  time  to  implement.  When  the  answer 
to  all  questions  is  yes,  then  the  challenge  is  to  figure  out  how  to  take  the  representation 
of  that  element  in  each  FOM  and  develop  the  mappings  and  conversions  to  move  data 
from  the  JSAF  model  to  the  VMSA  simulation  (and  vice  versa)  and,  most  importantly, 
have  it  mean  the  same  thing  to  both  sides. 

In  some  cases,  there  may  be  multiple  ways  to  represent  something  in  the  RPR  2.0 
FOM.  (This  may  also  be  true  for  the  VMSA  FOM,  but  since  only  developers  at 
DRDC  Atlantic  are  concerned  with  this,  the  choice  is  not  of  concern  to  other  WIB 
members.)  For  example,  in  the  RPR  FOM  AcousticSignaturelndex  is  an  attribute  of 
PhysicalEntity  so  it  is  possible  to  pass  acoustic  signatures  and  changes  in  them,  via 
HLA.  While  this  may  make  sense  for  some  simulations,  others  (such  as  those  being 
used  in  the  VMSA  federation)  may  have  internal  representations  for  the  acoustic 
signatures  of  particular  platforms,  and  therefore  require  the  EntityType  attribute  of  the 
BaseEntity  object  so  that  it  can  look  up  the  appropriate  signature.  Both  methods  are 
legitimate  applications  of  the  RPR  2.0  FOM,  but  if  the  two  methods  are  adopted  by 
different  federates  in  a  federation,  it  will  not  function  as  intended. 

Since  the  federates  for  WIB  are  from  defence  organizations  across  Canada,  there  is  no 
single  person  that  has  knowledge  of  every  federate.  Thus,  documentation  on  the  RPR 
2.0  implementation  appropriate  for  each  federate  has  been  requested  from  the 
responsible  parties.  Once  gathered,  collective  decisions  can  be  made  on  the 
implementations  that  will  be  used  for  WIB. 

1.5  About  This  Paper 

This  paper  provides  descriptions  of  the  sensor  and  weapon  models  that  will  be  used  to 
simulate  the  enemy  submarine  and  identifies  configurable  parameters  and  required 
data  agreements.  A  brief  discussion  of  damage  modelling  for  VMSA  is  also  included. 
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Most  importantly,  it  proposes  VMSA  and  RPR  2.0  FOM  objects  and  interactions  to  be 
used  to  satisfy  the  communication  requirements  of  the  submarine  with  other  WIB 
federates.  Relevant  object  attributes  and  interaction  parameters  are  included  as  well. 
Descriptions  of  such  attributes  and  parameters  are  included  in  the  tables  and  taken 
directly  from  [1]  in  the  case  of  RPR  2.0  objects  and  interactions  and  from  [2]  for 
VMSA  objects  and  interactions. 

It  should  be  noted  that  since  the  requirements  of  all  federates  will  not  be  known  until 
all  such  papers  are  completed,  additions  or  modifications  to  this  document  may  be 
made  at  a  later  time. 

1.6  War-in-a-Box  Set-Up 

Figure  1  illustrates  the  anticipated  set-up  for  WIB.  It  does  not  explicitly  display  all 
WIB  federates,  rather  it  highlights  the  ones  of  interest  to  this  paper.  A  brief 
description  of  each  federate  is  provided  below. 

The  federates  are: 

•  Passive  Sonar  -  simulation  of  a  passive  sonar  system  for  the  detection  of 
sound  produced  by  other  platforms.  A  signal  follower  is  included  for  the 
creation  of  time-bearing  tracks. 

•  ESM  -  simulation  of  an  Electronic  Support  Measures  (ESM)  system  for  the 
detection  of  radar  on  other  platforms  and  outputting  time -bearing  tracks. 

•  Horizon  -  a  command  and  control  /  track  management  system  that  is  used  to 
display  and  manipulate  sensor  tracks,  including  those  from  the  passive  sonar 
and/or  ESM  federates.  Horizon  uses  a  VMSA  plug-in  to  receive  entity  and 
track  data  from  the  VMSA  federation,  and  its  own  communication  protocol 
referred  to  as  6 Promotion  Comms’  to  promote  tracks  from  one  Horizon 
instance  to  another.  It  includes  a  plan  view  display,  useful  for  operators 
involved  with  platform  navigation,  as  well  as  an  interface  for  launching 
torpedoes  from  the  submarine. 

•  Sound  -  plays  a  sound  file  when  weapons  are  launched  or  active  sonar  pings 
are  received. 

•  JSAF  -  a  constructive  simulation  environment  for  the  creation  of  entities 
(e.g.,  platforms,  humans)  with  weapons  and  sensors  from  all  environments 
(with  a  focus  on  the  maritime  environment  for  WIB).  Operators  can  assign  a 
series  of  (override-able)  tasks  to  each  entity  and  they  will  be  performed 
realistically,  according  to  the  built-in  Task  frame  intelligence’. 

•  Tacoma  -  a  software  bridge  enabling  meaningful  data  exchange  between  two 
systems.  In  the  case  of  WIB,  these  systems  are  VMSA  and  RPR  2.0 
federations  and  Tacoma  consists  of  both  federate  and  non-federate 
components.  The  ‘on-ramps’  are  federates  responsible  for  the  direct 
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communication  with  their  respective  federations.  The  Translators’  turn  FOM 
data  into  XML  and  XML  data  to  FOM  data.  The  ‘spans’  provide  the  actual 
means  for  communication  between  one  federation  and  the  other  [3]. 


MAK  RT1,  RPR  2.0  FOM 


DMSO  RTI,  VMSA  FOM 


Figure  1.  Federates  and  Simulation  Components  Relevant  to  VMSA  Submarine  Integration 
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2.  Physical  Entities 


Many  of  the  federates  discussed  in  this  paper  require  other  federates  to  share 
information  about  the  platforms  they  create  and/or  control.  To  prevent  the  repetition 
of  this  information  throughout  the  paper,  it  is  presented  in  this  initial  section  and  will 
be  referred  to  when  it  is  relevant  to  a  particular  federate. 

2.1  VMSA  Entities 

In  VMSA,  composite  entities  are  defined  as  entities  that  exist  “in  their  own  right”. 
For  example,  ships,  submarines,  and  aircraft  are  composite  entities.  Weapons  such  as 
missiles  and  torpedoes  which  are  modelled  individually  are  also  included  in  this 
category. 


Table  1.  Composite  Entity  Attributes 


OBJECT 

ATTRIBUTE 

DESCRIPTION 

CompositeEntity 

Name 

Specifically  identifies  a  particular  instance  of  a  CompositeEntity.  Composed  of 
a  concatenation  of  terms,  each  of  which  conveys  a  well-defined  characteristic 
of  the  entity. 

Description 

Provides  a  user  defined  description  of  a  CompositeEntity. 

Affiliation 

Names  the  organisation  the  CompositeEntity  is  a  member  of. 

Role 

Describes  the  role  currently  being  executed  by  a  CompositeEntity. 

Position 

The  position  of  a  reference  point  of  the  CompositeEntity.  The  position  is  given 
with  respect  to  the  WGS84  Cartesian  coordinate  system. 

Velocity 

The  velocity  of  the  CompositeEntity.  The  velocity  components  are  given  with 
respect  to  the  WGS84  Cartesian  coordinate  system. 

Acceleration 

The  acceleration  of  the  CompositeEntity.  The  components  of  the  acceleration 
are  given  with  respect  to  the  WGS84  Cartesian  coordinate  system. 

Orientation 

The  orientation  of  a  coordinate  system  fixed  to  the  CompositeEntity  with 
respect  to  the  WGS84  Cartesian  coordinate  system.  The  origin  of  this 
coordinate  system  is  given  by  the 

Position  attribute. 

Orientation  Rate 

The  rate  of  change  of  the  Euler  angles  that  define  the  orientation  of  a 
coordinate  system  fixed  to  the  CompositeEntity  with  respect  to  the  WGS84 
Cartesian  coordinate  system. 

DRAlgorithm 

Specifies  the  algorithm  used  to  dead  reckon  the  kinematic  attributes  of  the 
CompositeEntity. 

The  Affiliation  attribute  can  take  on  one  of  three  values  as  indicated  in  Table  2. 


Table  2.  Affiliation  Attribute  Values 


AFFILIATION 

DESCRIPTION 

1 

Blue 

2 

Red 

3 

Green 

The  DRAlgorithm  attribute  can  take  on  one  of  eleven  values.  However,  the  dead 
reckoning  algorithm  currently  used  by  all  VMSA  federates  is  DRAlgorithm  =11 
which  uses  both  velocity  and  acceleration  to  estimate  current  position  and  uses 
orientation  rate  to  estimate  current  orientation.  VMSA  can  also  support  the  other 
(less  accurate)  dead  reckoning  algorithms  listed  in  Section  4  of  [4]. 
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2.2  RPR  2.0  Entities 


Similarly  in  RPR  2.0,  physical  entities  include  ships,  submarines,  missiles,  torpedoes, 
etc.. 


Table  3.  Physical  Entity  Data  Attributes 


OBJECT 

ATTRIBUTE 

DESCRIPTION 

BaseEntity.PhysicalEntity 

Entityldentifier 

Identifies  the  site,  application,  and  entity  of  this  object  instance. 

EntityType 

Kind,  Country,  Domain,  Category,  Subcategory,  Specific,  and 
Extra  fields  of  the  DIS  Entity  type. 

Spatial 

Used  to  express  the  spatial  relationship  between  the  entity  and 
the  centre  of  the  earth. 

Forceldentifier 

Enumeration  distinguishing  the  different  teams  or  sides  in  an 
exercise. 

The  Forceldentifier  attribute  can  take  on  one  of  four  values  are  indicated  in  Table  4. 
Table  4.  Forceldentifier  Attribute  Values 


FORCE 

IDENTIFIER 

DESCRIPTION 

0 

Other 

1 

Friendly 

2 

Opposing 

3 

Neutral 

The  Spatial  variant  record  attribute  includes  six  data  elements  to  define  the  spatial 
information  of  an  entity  as  shown  in  Table  5. 


Table  5.  Spatial  Variant  Record  Data  Elements 


ATTRIBUTE 

DATA  ELEMENTS 

DESCRIPTION 

Spatial 

AccelerationVector 

The  magnitude  of  the  change  in  linear  velocity  of  an  object  over  time. 

AngularVelocityVector 

The  rate  at  which  an  entity's  orientation  is  changing  over  time. 

DeadReckoningAlgorithm 

Dead  reckoning  algorithm  used  by  the  issuing  object. 

Orientation 

The  angles  of  rotation  around  the  coordinate  axes  between  the  entity's 
attitude  and  the  reference  coordinate  system  axes  (calculated  as  the 
Tait-Bryan  Euler  angles  specifying  the  successive  rotations  needed  to 
transform  from  the  world  coordinate  system  to  the  entity  coordinate 
system). 

VelocityVector 

The  rate  at  which  an  entity's  position  is  changing  over  time. 

WorldLocation 

Location  of  the  entity. 

The  DeadReckoning  Algorithm  can  take  on  one  of  nine  values. 
DeadReckoningAlgorithm  =  9  is  equivalent  to  DRAlgorthim  =11  which  is  typically 
used  in  VMSA  federates.  (The  Distributed  Interactive  Simulation  (DIS)  enumeration 
guide  [4]  refers  to  this  algorithm  as  DRM(F,V,B).  A  description  of  these  terms  is 
(oddly)  not  provided  in  the  DIS  enumeration  document,  but  can  be  found  in  [5].) 
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3.  Submarine  Sensors 


This  section  describes  the  sensor  models  that  will  be  used  for  the  red  submarine  for  the 
WIB  exercise.  As  all  of  these  sensors  are  of  a  passive  nature,  only  data  subscription 
requirements  are  relevant  and  discussed. 


3.1  Passive  Sonar 

3.1.1  Model  Description 

The  passive  sonar  federate  was  developed  at  DRDC  Atlantic  and  uses  basic 
sonar  equations  with  some  modifications  to  handle  beam-forming.  It  can  be 
configured  as  broadband  and/or  narrowband  sonar.  For  each  entity  that 
should  be  detectable  by  the  sonar  instance,  the  acoustic  signature  of  the 
platform  is  looked  up  in  a  target  profile  file  internal  to  the  model  itself.  This 
file  may  be  defined  very  generally  such  that,  for  example,  all  warships  have 
the  same  signature,  or  very  specifically,  such  that  a  signature  applies  to  only 
one  specific  platform.  Transmission  loss  calculations  use  spherical  and/or 
cylindrical  spreading  and  absorption.  Ambient  noise  calculations  consider 
shipping  level,  rain  state,  and  sea  state.  Alternatively,  transmission  loss  and 
ambient  noise  can  be  input  through  data  files.  These  inputs  are  used  to 
develop  beam  maps  which  are  then  passed  to  a  signal  follower/tracker  to 
identify  tracks.  The  data  output  from  this  federate  is  therefore  at  the  track 
level. 

This  model  does  not  address  the  concept  of  the  water  surface  or  any  medium 
besides  water  and  therefore  is  not  able  to  model  the  detection  of  aircraft. 
Thus,  in  it  current  form,  only  the  detection  of  surface  and  subsurface  entities 
are  considered.  Detection  of  air  platforms  will  be  considered  in  a  future 
version  of  the  sonar  federate. 

3. 1 . 1 . 1  Configurable  Data 

The  passive  sonar  federate  provides  four  areas  for  configuration: 
environment,  the  sonar  itself,  the  tracker,  and  the  target  profiles. 
Only  the  parameters  most  relevant  to  WIB  are  highlighted  in  this 
paper.  The  complete  details  are  available  in  [6]. 

For  the  environment,  average  sound  speed,  ocean  depth,  shipping 
level  (from  l(low)  to  9  (high)),  sea  state  (from  l(low)  to  7  (high)), 
and  rain  state  (NoRain,  Intermediate,  Moderate,  Heavy)  may  be 
defined. 

For  the  sonar,  the  frequency  range  for  broadband  operation  is  set 
by  providing  the  central  frequency  for  the  band  and  the 
bandwidth.  For  narrowband  operation,  the  minimum  and 
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maximum  frequency  must  be  provided.  A  ‘WatchSide’  parameter 
is  set  to  “Both”  for  a  towed  array  or  to  “Port”  or  “Starboard”  for 
flank  arrays.  In  the  case  of  a  flank  array,  two  sonar  federates  are 
run,  one  for  each  side.  The  position  of  the  sonar  system  with 
respect  to  the  host  entity  is  currently  not  configurable.  It  is 
assumed  to  be  located  at  the  centre  of  the  host  entity. 

For  each  target  in  the  target  profiles  file,  a  name  with  at  least  one 
tone  for  narrow  band  detection  and  two  tones  for  broadband 
detection  are  required.  The  tones  for  use  by  narrow  band  sonar 
have  three  attributes:  central  frequency,  bandwidth,  and  signal 
level;  for  any  frequency  in  the  defined  bandwidth,  the  signal  level 
is  as  indicated.  The  tones  used  by  broad  band  sonar  have  two 
attributes:  frequency  and  signal  level.  The  signal  level  for  a 
particular  frequency  is  determined  by  interpolating  between  the 
points  defined  in  the  file.  There  is  a  limitation  here  in  that  signal 
level  is  based  solely  on  the  type  of  platform  and  does  not  consider 
the  state  of  the  platform  (e.g.,  its  speed). 


3.1.2  FOM  Requirements 

For  this  federate,  only  platform  information  for  surface  entities  is  required,  as 
presented  in  Table  3  for  the  RPR  2.0  FOM.  This  information  is  mapped  to 
composite  entities  in  the  VMSA  FOM  (Table  1)  to  which  the  VMSA  passive 
sonar  federate  subscribes.  (The  sonar  federate  publishes  sonar  tracks  to  the 
VMSA  federation,  but  these  are  not  passed  into  the  RPR  2.0  world  and  are 
thus  not  important  to  this  document.) 

3.1 .3  Data  Agreements 

Appropriate  and  meaningful  values  for  average  sound  speed,  average  ocean 
depth,  shipping  level,  sea  state,  and  rain  state  must  be  identified.  Acoustic 
target  profiles  for  every  entity  in  the  WIB  scenario  that  could  conceivably  be 
detected  by  passive  sonar  (e.g.,  ships,  submarines,  torpedoes,  etc.)  must  be 
defined.  Sonobuoys  modelled  outside  of  VMSA  will  also  need  these  target 
profiles  so  common  data  must  exist  for  both  models. 

3.2  ESM 

3.2.1  Model  Description 

The  Electronic  Support  Measures  (ESM)  federate  [7]  was  developed  at  DSTO 
and  represents  a  generic  ESM  system  which  can  be  configured  to  reflect  the 
characteristics  of  a  particular  type  of  system.  It  detects  RF  emissions  of  radar 
systems  and  then  looks  at  the  tasking  information  for  that  radar.  The  task 
defines  the  radar’s  mode  which  is  looked  up  in  a  table  along  with  the 
component  name  of  the  radar  to  obtain  its  operating  configuration  (e.g., 
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frequency,  effective  radiated  power  (ERP),  pulse  width  (PW),  and  pulse 
repetition  frequency  (PRF)).  The  radar  emissions  that  can  be  detected  by 
ESM  must  fall  within  the  minimum  and  maximum  ERP,  PW,  and  PRF  ranges 
specified  for  that  ESM  system.  The  elevation  of  the  radar  with  respect  to  the 
ESM  must  also  be  within  a  predefined  range.  If  these  things  do  not  hold, 
received  power  is  0.  Otherwise,  if  radar  is  on,  the  range  to  the  radar  is 
calculated  and  it  is  determine  whether  there  is  line  of  sight  to  the  radar  and  if 
the  radar  beam  is  in  the  direction  of  the  ESM.  If  all  of  these  are  true,  the 
signal  power  is  calculated  (considering  antenna  gains  and  losses,  radiated 
power,  wavelength  and  range)  and  is  used  to  determine  whether  or  not  a 
detection  is  made.  After  a  certain  number  of  detections  are  made,  a  new  track 
is  started.  As  with  the  sonar  federate,  the  outputs  of  this  federate  are  time¬ 
bearing  tracks. 

3. 2. 1 . 1  Configurable  Data 

For  each  ESM  system,  configurable  characteristics  include 
maximum  and  minimum  detection  ranges  for  RF,  PW,  and  PRF 
and  antenna  gain  and  losses.  For  each  potential  combination  of  a 
radar  and  task,  frequency,  ERP,  PW,  PRF  are  defined. 

3.2.2  FOM  Requirements 

3.2.2.1  VMSA 

Platform  information  for  surface  and  air  entities  is  required  as 
shown  in  Table  1 .  In  addition  to  this  data,  the  radar  and  radar  task 
information  is  required  as  described  in  Table  6.  (The  ESM 
federate  publishes  ESM  tracks  to  the  VMSA  federation,  but  these 
are  not  passed  into  the  RPR  2.0  world  and  are  not  important  to 
this  document.) 

The  Status  attribute  of  the  ComponentEntity  object  can  take  on  one 
of  four  values  as  indicated  in  Table  7. 
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Table  6.  Relevant  VMSA  FOM  Elements  for  ESM 


OBJECT 

ATTRIBUTE 

DESCRIPTION 

ComponentName 

This  attribute  provides  a  description  of  a  ComponentEntity.  This  attribute  is 
composed  of  a  concatenation  of  terms,  each  of  which  conveys  a  well-defined 
characteristic  of  the  entity. 

Status 

Describes  the  status  of  a  component  entity. 

ComponentEntity 

RelativePosition 

The  position  of  the  ComponentEntity  relative  to  the  reference  point  of  the  parent 
CompositeEntity.  The  position  is  given  with  respect  to  the  coordinate  system 
fixed  to  the  parent  CompositeEntity. 

RelativeOrientation 

The  orientation  of  a  coordinate  system  fixed  to  the  ComponentEntity  relative  to 
the  coordinate  system  fixed  to  the  parent  CompositeEntity. 

ParentCompositeEntity 

ObjectlnstanceName 

The  object  instance  name  of  the  CompositeEntity  that  is  the  parent  of  the 
ComponentEntity.  This  attribute  is  used  to  identify  which  CompositeEntity 
kinematic  attributes  should  be  used  in  conjunction  with  the  RelativePosition  and 
RelativeOrientation  attributes  to  derive  the  kinematic  attributes  of  the 
ComponentEntity. 

TaskName 

Specifies  a  task  performed  by  a  system.  This  attribute  is  composed  of  a 
concatenation  of  terms,  each  of  which  conveys  a  well-defined  characteristic  of 
the  task.  A  single  system  may  perform  any  number  of  tasks. 

On 

This  is  a  boolean  attribute  which  is  True  if  the  task  is  operable  and  False 
otherwise. 

RelativePosition 

The  position  of  the  origin  of  the  coordinate  system  associated  with  the  signal 
task  relative  to  the  reference  point  of  the  parent  CompositeEntity.  The  position 
is  given  with  respect  to  the  coordinate  system  fixed  to  the  parent 

CompositeEntity. 

Signal  Pattern  Reference 

Defines  the  coordinate  system  with  respect  to  which  the  signal  pattern  is 
specified. 

SignalT  ask.  ActiveT  ask.  R 
FTask.RadarTask  (S) 

SignalPatternOrientation 

The  orientation  of  a  coordinate  system  fixed  to  the  beam  pattern,  given  with 
respect  to  the  coordinate  system  specified  by  the  SignalPatternReference 
attribute. 

SignalPatternOrientationRate 

Depending  on  the  dead-reckoning  algorithm  used,  either  the  rate  of  change  of 
the  Euler  angles  that  define  the  orientation  of  the  signal  pattern  coordinate 
system  (S)  with  respect  to  the  reference  coordinate  system,  or  the  angular 
velocity  of  the  S  coordinate  system  with  respect  to  the  reference  coordinate 
system,  with  components  of  the  angular  velocity  measured  with  respect  to  a 
stationary  frame  instantaneously  coincident  with  the  S  frame. 

SignalPatternDRAIgorithm 

The  algorithm  used  to  dead  reckon  the  Euler  angles  that  specify  the  orientation 
of  the  signal  pattern  associated  with  this  task. 

ComponentObjectlnstance 

Name 

The  object  instance  name  of  the  ComponentEntity.SensorSystem  that 
represents  the  sensor  system  that  this  task  is  associated  with. 

ParentCompositeEntityObject 

InstanceName 

The  object  instance  name  of  the  CompositeEntity  that  is  the  parent  of  the 
ComponentEntity  that  is  responsible  for  generating  the  SignalTask. 

CentreFrequency 

Centre  or  carrier  frequency  of  the  active  signal  task. 

RadarTask 

Instances  of  this  object  class  describe  those  tasks  performed  by  a  radar. 

Table  7.  Status  Attribute  Values 


STATUS 

DESCRIPTION 

1 

Standby 

2 

Active 

3 

Disabled 

4 

Silence 

3.2.2.2  RPR  2.0 

Platform  information  for  surface  and  air  entities  is  required  as 
shown  in  Table  3.  In  addition  to  this  data,  the  radar  (emitter 
system)  and  beam  information  is  required  as  described  in  Table  8. 
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Table  8.  Relevant  RPR  2.0  FOM  Elements  for  ESM 


OBJECT 

ATTRIBUTE 

DESCRIPTION 

HostObjectldentifier 

Object  instance  ID  of  the  host  to  which  the  object  instance  is  attached. 

RelativePosition 

Location  of  the  embedded  system  relative  to  the  host’s  position. 

EmbeddedSystem.EmitterSystem 

Entityldentifier 

Identifies  the  site,  application,  and  entity  number  of  the  host  to  which 
the  object  instance  is  attached. 

(S) 

Emitterlndex 

Specifies  the  identification  number  for  each  emitter  system  on  a  given 
host. 

EmitterFunctionCode 

Specifies  the  function  for  a  particular  emitter  as  an  enumeration. 

EmitterType 

EmitterType  specified  as  an  enumeration. 

BeamParameterlndex 

This  attribute  specifies  a  beam  parameter  index  number  that  shall  be 
used  by  receiving  entities  in  conjunction  with  the  emitter  name 
attribute  (EmitterSystem  object  class)  to  provide  a  pointer  to  the 
stored  database  parameters  required  to  regenerate  the  beam. 

BeamAzimuthCenter 

This  attribute  specifies  the  azimuth  centre  angle  of  the  beam's  scan 
volume  relative  to  the  emitter  system.  This  attribute  in  conjunction 
with  BeamElevationCenter,  BeamAzimuthSweep,  and 
BeamElevationSweep  describes  the  scan  volume  covered  by  the 
emitter  beam  scan. 

BeamAzimuthSweep 

This  attribute  specifies  the  azimuth  sweep  of  the  beam's  scan-volume 
relative  to  the  azimuth  centre.  This  attribute  in  conjunction  with 
BeamAzimuthCenter,  BeamElevationCenter,  and 

BeamElevationSweep  describes  the  scan  volume  covered  by  the 
emitter  beam  scan. 

BeamElevationCenter 

This  attribute  specifies  the  elevation  centre  angle  of  the  beam's  scan- 
volume  relative  to  the  emitter  system.  This  attribute  in  conjunction 
with  BeamAzimuthCenter,  BeamAzimuthSweep,  and 
BeamElevationSweep  describes  the  scan  volume  covered  by  the 
emitter  beam  scan. 

This  attribute  specifies  the  elevation  sweep  of  the  beam's  scan 
volume  relative  to  the  BeamElevationCenter.  This  attribute  in 

BeamElevationSweep 

conjunction  with  BeamAzimuthCenter,  BeamAzimuthSweep  and 
BeamElevationCenter  describes  the  scan  volume  covered  by  the 
emitter  beam  scan. 

BeamFunctionCode 

This  enumerated  attribute  specifies  the  beam's  function.  It  serves  as 
a  general  data  filter. 

EmitterBeam 

Beamldentifier 

This  attribute  specifies  a  unique  database  number  assigned  to 
differentiate  between  otherwise  similar  or  identical  emitter  beams 
within  an  emitter  system. 

EffectiveRadiatedPower 

This  attribute  specifies  the  EffectiveRadiatedPower  for  the  emission  in 
dBm.  For  a  radar  or  a  noise  jammer,  this  attribute  shall  indicate  the 
peak  of  the  transmitted  power.  Thus,  it  includes  peak  transmitter 
power,  transmission  line  losses,  and  peak  of  the  antenna  gain. 

EmissionFrequency 

This  attribute  specifies  the  frequency  of  the  emission  in  hertz. 

Frequency  modulation  for  a  particular  emitter  and  mode  shall  be 
derived  from  database  parameters  by  the  reflecting  federate. 

EmitterSystemldentifier 

This  attribute  specifies  a  reference  to  the  emitter  system  object  from 
which  the  beam  is  emanating. 

Eventldentifier 

Used  by  the  generating  federate  to  associate  EmitterSystem  and 
EmitterBeam  changes. 

FrequencyRange 

This  attribute  specifies  the  bandwidth  of  the  frequencies 
corresponding  to  the  Frequency  attribute.  Thus,  if,  for  operational 
purposes,  the  Frequency  is  supposed  to  be  a  single  number,  then  the 
Frequency  Range  shall  be  zero 

PulseRepetitionFrequency 

This  attribute  specifies  the  average  PulseRepetitionFrequency  of  the 
emission  in  hertz.  PulseRepetitionFrequency  modulation  for  a 
particular  emitter  and  mode  shall  be  derived  from  database 
parameters  by  the  reflecting  federate. 

PulseWidth 

This  attribute  specifies  the  average  pulse  width  of  the  emission  in 
microseconds.  Pulse  modulation  for  a  particular  emitter  and  mode 
shall  be  derived  from  database  parameters  by  the  reflecting  federate. 

SweepSynch 

This  attribute  is  provided  to  allow  a  receiver  to  synchronize  its 
regenerated  scan  pattern  to  that  of  the  emitter.  This  attribute  when 
employed  specifies  the  percentage  of  time  a  scan  is  through  its 
pattern  from  its  origin.  The  pattern  and  origin  data  are  derived  from 
database  parameters. 
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The  enumeration  list  for  the  EmitterFunctionCode  attribute  of  the 
EmitterSystem  can  be  found  in  [4];  there  are  97  entries  and  thus 
they  are  not  all  listed  here.  The  codes  represent  functions  such  as 
ranging,  tracking,  and  navigation. 


The  BeamFunctionCode  attribute  of  the  EmitterBeam  object  can 
take  on  one  of  17  values  as  indicated  in  Table  9. 


3.2.3  Data  Agreements 

RF  emissions  for  each  ship  or  air  radar  in  the  WIB  scenario  that  could 
conceivably  be  detected  by  ESM  must  be  defined. 


Table  9.  BeamFunctionCode  Attribute  Values 


STATUS 

DESCRIPTION 

1 

Search 

2 

Height  finder 

3 

Acquisition 

4 

Tracking 

5 

Acquisition  and  tracking 

6 

Command  guidance 

7 

Illumination 

8 

Range  only  radar 

9 

Missile  beacon 

10 

Missile  fuze 

11 

Active  radar  missile  seeker 

12 

Jammer 

13 

IFF 

14 

Navigational  /  Weather 

15 

Meteorological 

16 

Data  transmission 

17 

Navigational  directional  beacon 

3.3  “Intercept”  Sonar 

This  federate  is  being  developed  at  DRDC  Atlantic  to  fill  a  requirement  for  the  WIB 
submarine  to  have  an  ability  to  detect  enemy  torpedo  launches  and  dipping  sonar 
pings,  and  is  more  commonly  referred  to  as  the  ‘sound  federate’.  These  sounds  would 
not  be  detected  by  the  passive  sonar  model  that  is  being  used;  rather  they  would  be 
ignored  by  the  tracker  due  to  their  transient  nature.  (The  torpedo  itself,  however,  as  it 
moves  through  the  water  towards  its  target,  may  be  detected  by  the  passive  sonar 
model.  The  sound  federate  is  only  concerned  with  the  launch.) 

In  an  effort  to  provide  a  limited  detection  capability  quickly,  a  federate  is  being 
created  which  simply  subscribes  to  specific  objects  and  interactions  and  plays  a 
corresponding  sound  when  there  is  a  match.  For  example,  when  a  torpedo  is 
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launched,  the  sound  of  a  torpedo  being  launched  will  be  played.  At  this  point, 
directional  information  is  not  being  provided  and  there  is  no  consideration  for  which 
platform  is  producing  the  sound,  but  these  are  desired  enhancements. 

For  WIB,  the  submarine  is  only  concerned  with  torpedoes  and  pings  originating  in  the 
RPR  2.0  federation.  For  this  reason,  the  federate  needs  to  be  compiled  as  a  RPR  2.0 
federate  and  subscribe  to  RPR  2.0  objects  and/or  interactions.  (Making  it  a  RPR  2.0 
federate  prevents  the  bridge  from  needing  to  translate  data  between  the  two 
federations.)  This  federate  will  be  run  in  the  red  submarine  simulation  room  during 
the  WIB  exercise  and  will  only  be  heard  by  the  ‘crew’  of  the  red  submarine. 

3.3.1  FOM  Requirements 

The  RPR  2.0  interaction  and  object  that  may  be  used  to  indicate  torpedo 
launching  and  sonar  pinging  are  shown  in  Table  10. 


Table  10.  Relevant  RPR  2.0  FOM  Elements  for  Sound 


OBJECT/INTERACTION 

ATTRIBUTE 

DESCRIPTION 

EmbeddedSytem.UnderwaterAcoustics. 
ActiveSonar  (S) 

FunctionCode 

Indicates  the  main  purpose  of  the  active 
sonar. 

WeaponFire  (S) 

MunitionType 

The  type  of  munition  being  fired. 

Table  1  describes  the  possible  values  of  the  FunctionCode  attribute. 


Table  11.  Relevant  RPR  2.0  FOM  Elements  for  Sound 


FUNCTION 

CODE 

DESCRIPTION 

0 

Other 

1 

Platform  search/detect/track 

2 

Navigation 

3 

Mine  Hunting 

4 

Weapon  search/detect/track/detect 

The  sound  federate  will  play  a  sonar  ping  sound  file  whenever  the  function 
code  is  set  to  1  (Platform  search/detect/track).  The  file  will  be  replayed  at  a 
fixed  interval  until  the  function  code  changes. 

Similarly,  it  will  play  a  torpedo  launch  sound  file  whenever  the  WeaponFire 
interaction  is  published  and  the  MunitionType  is  appropriate  for  attacking  a 
submarine.  (This  prevents  the  sound  from  playing  when  the  ship  launches  a 
missile  at  a  hostile  air  platform.) 

3.3. 1 . 1  Configurable  Data 

The  sound  files  that  will  be  used  by  the  federate  can  be  set  in  the 
configuration  file. 
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3.3.2  Data  Agreements 

This  federate  needs  to  know  all  possible  weapon  types  that  could  be  launched 
at  the  submarine. 
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4.  Submarine Torpedoes 


This  section  considers  the  HLA  communication  required  between  the  VMSA 
simulation  of  the  red  submarine  and  the  RPR  2.0  federate,  JSAF,  in  order  to  fully 
model  red  force  torpedoes. 

4.1  Torpedoes 

The  red  submarine  needs  the  capability  of  launching  torpedoes  at  the  blue  ships.  As 
this  was  not  an  existing  capability,  it  was  decided  that  the  decision  to  launch  the 
torpedo  would  be  made  by  an  operator  on  the  red  sub  (simulated  by  the  VMSA 
federation),  but  the  actual  creation,  launch  and  control  of  the  torpedo  would  be  the 
responsibility  of  JSAF  in  the  RPR  2.0  federation.  Within  the  Horizon  Command  and 
Control  (C2)  software,  a  plug-in  was  developed  to  set  the  torpedo’s  launch  criteria, 
including  the  type  of  torpedo,  the  launch  bearing  and  the  range  at  which  to  turn  on  the 
torpedo’s  acoustic  sensing  system.  Torpedoes  are  launched  one  at  a  time,  but  may  be 
launched  in  quick  succession  if  desired.  While  JSAF  controls  the  torpedo  entity,  its 
position  will  be  mirrored  in  the  Horizon  plan  view  display. 


4.1.1  FOM  Requirements 

4.1  A  A  VMSA 

The  VMSA  Launch  interaction  is  required  and  is  described  in 
Table  12. 

Table  12.  Relevant  VMSA  FOM  Elements  for  Torpedo  Launching 


INTERACTION 

PARAMETERS 

DESCRIPTION 

ControlMessage. 
LaunchControl. 
Launch  (P) 

InitiatorObject 

InstanceName 

Identifies  the  object  instance  that  has  initiated 
the  interaction. 

ControlMessagelD 

Provides  an  identifier  of  this  message  that  is 
unique  to  the  sender.  (1,2,3,...). 

Plan 

The  details  of  the  launch  plan.  The  format  for 
this  plan  is  agreed  to  by  the  initiating  and 
receiving  federates  during  federation  design 
(XML  format) 

EntityName 

The  name  of  the  entity  to  launch.  (This  is  left 
blank  since  the  name  is  expected  to  be 
assigned  by  JSAF). 

The  Plan  parameter’s  format  is  not  explicitly  defined  by  the  FOM. 
It  is  up  to  the  scenario  developers  to  define  the  details  of  this 
parameter.  For  the  purposes  of  WIB  it  has  been  defined  as  shown 
in  Table  13. 
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Table  13.  Relevant  Elements  of  Launch  Interaction’s  Plan  Parameter 


DATA  ELEMENT 

MEANING 

WeaponType 

The  type  of  weapon  being  launched. 

LaunchBearing 

The  bearing  at  which  to  launch  the  torpedo,  relative  to  the 
platform  launching  the  torpedo. 

WeaponActiveRange 

Range  at  which  to  turn  on  acoustic  homing. 

The  torpedo  itself  is  modelled  in  JSAF  and  displayed  in  Horizon. 
In  VMSA,  a  torpedo  is  modelled  as  a  CompositeEntity 
.SubSurface  entity.  The  attributes  for  this  entity  were  shown  in 
Table  1. 

4.1: 1.2  RPR  2.0 

The  VMSA  launch  interaction  is  translated  into  a  RPR  2.0 
WeaponFire  interaction  by  the  bridge.  The  WeaponFire 
interaction  is  as  shown  in  Table  14. 


Table  14.  Relevant  RPR  2.0  FOM  Elements  for  Torpedo  Launching 


ATTRIBUTE 

ATTRIBUTE 

DESCRIPTION 

Eventldentifier 

An  ID  generated  by  the  issuing  federate  used  to 
associate  related  fire  and  detonation  events. 

FireControlSolution 

Range 

The  range  used  in  the  fire  control  solution.  Zero 
if  the  range  is  unknown  or  inapplicable. 

FireMissionlndex 

A  unique  index  to  identify  the  fire  mission  (used 
to  associate  weapon  fire  interactions  in  a  single 
fire  mission). 

FiringLocation 

The  location  in  the  world  coordinate  system  of 
the  weapon  fire. 

FiringObjectldentifier 

The  ID  of  the  object  firing  the  munition. 

WeaponFire 

FuseType 

The  type  of  fuse  on  the  munition. 

InitialVelocityVector 

The  velocity  vector  of  the  munition  when  fired. 

MunitionObject 

Identifier 

The  ID  of  the  associated  munition  object  (if  any). 

MunitionType 

The  type  of  munition  being  fired. 

QuantityFired 

The  number  of  rounds  fired  in  the  fire  event. 

RateOfFire 

The  rate  of  fire  at  which  the  munitions  in  the 
burst  described  in  the  fire  event. 

T  argetObjectldentifier 

The  ID  of  the  object  being  fired  at  (if  any). 

WarheadType 

The  type  of  warhead  fitted  to  the  munition  being 
fired. 

Since  torpedoes  will  only  be  launched  from  the  sub  one  at  a  time, 
there  will  be  a  separate  WeaponFire  interaction  associated  with 
each  torpedo  launch.  Therefore,  QuantityFired  is  always  ‘V  and 
RateOfFire  is  always  ‘1\  Also,  the  torpedo  destination  is 
determined  by  the  launch  bearing  and  sensor  activation  range,  so 
TargetObjectldentifier  will  always  be  blank. 

The  torpedoes  created  by  JSAF  are  expected  to  be  published  as 
BaseEntity.PhysicalEntity.Munition  entities  in  RPR  2.0  which 
will  be  translated  into  CompositeEntity. SubSurface  entities  in 
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VMSA.  The  BaseEntity.PhysicalEntity.Munition  entity  attributes 
were  shown  in  Table  3. 
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5.  Damage  Modelling 


Details  of  the  damage  modelling  capabilities  of  all  WIB  federates  were  also  requested 
by  the  WIB  technical  team.  However,  VMSA  currently  does  not  model  damage.  Prior 
to  WIB,  the  VC S  Group  did  not  have  a  method  to  launch  weapons  using  their  core 
VMSA  federates  so  damage  modelling  had  not  come  up  as  a  requirement.  Therefore, 
the  submarine  (VMSA  simulation)  is  expecting  JSAF  to  handle  its  damage  modelling. 
This  includes  informing  the  submarine  operators  when  the  sub  has  been  hit,  and  when 
the  sub  has  successfully  destroyed  any  blue  entities  that  it  launches  its  torpedoes  at. 

The  Canadian  Forces  Maritime  Warfare  Center  (CFMWC)  is  preparing  a  description 
of  JSAF’s  capabilities  and  requirements  in  terms  of  its  WIB  application,  similar  to  this 
one  for  the  VMSA  simulation.  Once  this  information  is  available,  a  better 
understanding  of  JSAF’s  damage  modelling  is  expected.  Until  this  time,  there  are  a 
few  foreseeable  implementations: 

•  The  damage  modelling  will  all  be  handled  through  RTI  calls  and  not 
involve  FOM  objects  or  interactions  at  all, 

•  JSAF  will  indicate  catastrophic  damage  by  sending  a  ‘remove  entity’  type 
of  interaction,  or 

•  Damage  information  will  simply  be  radioed  from  one  room  to  the  other 
and  the  JSAF  and/or  VMSA  operator(s)  will  manually  remove  the  entity 
that  has  been  destroyed.  A  nicety  of  this  method  is  that  the  scenario 
controllers  could  alternatively  radio  ‘passive  sonar  system  down’,  ‘ESM 
down’,  ‘Helm  control  down’  etc.  and  this  could  be  simulated  by  turning 
off  the  relevant  displays. 

Further  investigation  must  clearly  occur  on  this  topic. 


18 


DRDC  Atlantic  TM  2005-273 


6.  Blue  Force  Sensors 


This  section  considers  the  possible  methods  by  which  the  red  submarine  or  its 
weapons  may  be  detected.  In  order  to  enable  a  ‘fair  fight’,  the  sub  must  somehow 
announce  to  other  entities  that  it  is  raising  its  ESM  antenna,  periscope,  or  snorkel  or 
launching  a  torpedo. 


6.1  Radar 


When  the  submarine  raises  its  ESM  antenna,  periscope,  or  snorkel,  its  radar  cross 
section  (RCS)  changes.  In  VMSA,  RCS  is  currently  dependent  only  on  the  type  of 
platform  being  modelled  and  its  relative  position  to  the  radar,  so  ‘changing’  the  RCS 
is  an  unknown  concept.  Similarly,  in  JSAF,  the  RCS  calculation  accounts  for  the  type 
of  platform  (which  is  looked  up  in  a  table)  and  its  location  and  orientation.  Also, 
looking  through  some  of  the  JSAF  code  (since  the  details  of  JSAF  models  are  not 
well-documented),  the  concept  of  ‘PeriscopeUp’  exists,  suggesting  that  its  radar 
model  does  somehow  account  for  this  as  well.  While  the  RPR  2.0  FOM  provides  the 
opportunity  to  publish  RCS  for  all  entities,  this  does  not  fit  well  with  either  the 
VMSA  or  JSAF  modelling  concepts.  Reading  through  the  RPR  2.0  documentation 
[1]  and  in  particular  the  DIS  enumeration  document  [4],  the  most  fitting  way  to  model 
the  change  in  RCS  is  by  considering  the  periscope,  snorkel  and  ESM  antenna  as 
‘articulated  parts’  of  the  submarine;  that  is,  modelling  the  physical  changes  that  result 
in  an  RCS  change. 

It  should  be  noted  that  the  VMSA  does  not  currently  model  periscopes,  antennas,  or 
snorkels  at  all.  This  is  something  the  VCS  Group  must  find  a  ‘quick  fix’  for  prior  to 
WIB.  It  is  important  however  to  have  agreement  amongst  WIB  members  on  how 
these  things  will  be  captured  in  the  RPR  2.0  FOM  as  it  effects  how  such  a  fix  will  be 
realized. 

The  proposed  RPR  2.0  mapping  for  these  components  is  described  in  the  following 
FOM  section. 


6.1.1  FOM  Requirements 

Since  a  single  physical  entity  can  have  more  than  one  articulated  part,  such 
parts  are  represented  by  an  array,  as  indicated  in  Table  15.  In  addition,  the 
platform  information  for  subsurface  entities  is  required,  as  presented  in 
Table  3. 
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Table  15.  Relevant  RPR  2.0  FOM  Elements  for  Radar  Detection  of  Sub 


OBJECT 

ATTRIBUTE 

DESCRIPTION 

BaseEntity.PhysicalEntity. 
Platform.  SubmersibleVessel 

ArticulatedParametersArray 

Identification  of  the  visible  parts,  and  their 
states,  of  the  entity  which  are  capable  of 
independent  motion. 

Referring  to  [8],  the  fields  of  the  ArticulatedParametersArray  are  found  to  be: 


Table  16.  Fields  of  the  ArticulatedParametersArray  Attribute 


ATTRIBUTE 

FIELDS 

ArticulatedParametersArray 

#  Articulation  Parameters 

Parameter  Type  Designator* 

*  these  are  repeated  for  each 
articulated  part 

ID-Part  Attached  To  * 

Parameter  Type  * 

Parameter  Value  * 

Note  that  the  ‘Change  Indicator’  field  has  not  been  included  as  this  is 
assumed  to  be  a  DIS  concept,  rather  than  HLA.  Referring  to  [4],  the 
‘Parameter  Type  Designator’  field  can  take  on  two  values:  0  for  Articulated 
Parts  and  1  for  Attached  Parts.  The  periscope,  snorkel  and  ESM  antenna  are 
all  articulated  parts  and  therefore  the  value  of  this  field  will  be  0  for  each 
entry  in  the  array. 

The  ‘ID-Part  Attached  To’  field  will  always  have  a  value  of  0  since  these 
parts  are  each  attached  directly  to  the  sub,  rather  than  to  another  articulated 
part. 

The  ‘Parameter  Type’  field  uses  integer  values  to  indicate  both  the  kind  of 
part  (e.g.,  periscope)  and  the  parameter  of  interest  (e.g.,  position).  The 
following  indexes  are  found  in  [4]: 


Table  17.  Articulated  Part  Indices 


INDEX  (x) 

ARTICULATED  PART 

2048 

Periscope 

2080 

Generic  Antenna 

2112 

Snorkel 

The  following  offsets  from  these  indices  are  used  to  indicate  the  parameter  of 
interest.  (Only  relevant  offsets  are  shown  here.) 

Table  18.  Articulated  Part  Parameter  Offsets 


OFFSET 

PARAMETER 

x  +  1 

Position 

x  +  3 

Extension 

x  +  4 

Extension  Rate 

20 
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For  example,  for  the  position  of  the  periscope,  the  ‘Parameter  Type’  field’s 
value  would  be  2049. 

Finally,  the  ‘Parameter  Value’  field  is  the  actual  information.  For  example, 
for  ‘Parameter  Type’  2049,  the  ‘Parameter  Value’  would  be  the  position  of 
the  periscope  in  World  Coordinates. 


6.1 .2  Data  Agreements 

All  federates  modelling  radar  with  look-up  tables  should  have  comparable 
RCS  values  for  each  entity  in  a  given  state  (e.g.,  periscope  up). 

6.2  Passive  Sonar 

The  passive  sonar  that  will  be  used  on  the  frigates  is  the  same  as  the  model  that  is 
used  for  the  submarine.  While  the  ships  will  be  controlled  by  JSAF  within  the  RPR 
2.0  federation,  their  passive  sonar  is  modelled  fully  within  VMSA.  This  means  that 
JSAF  entities  will  not  automatically  react  to  passive  acoustic  information,  and  it  will 
be  up  to  the  JSAF  operators  to  decide  if  action  (e.g.,  course  change)  needs  to  be  taken 
based  on  information  in  the  passive  sonar  (Horizon)  display.  For  details  of  the  model, 
the  HLA  implementation,  and  the  configurable  parameters,  refer  back  to  Section  3.1. 

6.3  Dipping  Sonar,  Active  Sonar  and  Sonobuoys 

It  is  expected  that  the  entity  data  in  Table  1  (for  VMSA)  and  Table  3  (for  RPR  2.0) 
will  be  sufficient  for  the  dipping  and  active  sonar  as  well  as  the  sonobuoys.  VMSA 
entities  do  not  currently  publish  Target  or  Acoustic  Signatures.  Rather,  models  that 
would  be  interested  in  these  signatures  contain  internal  tables  mapping  the  platform’s 
type  to  a  signature.  The  authors  suspect  a  similar  implementation  in  JSAF,  which  will 
be  confirmed  upon  receipt  of  the  JSAF  implementation  document. 

6.3.1  Data  Agreements 

Since  JSAF  is  modelling  passive  acoustics  for  sonobuoys  and  VMSA  is 
modelling  passive  sonar  for  ships  and  the  submarine,  it  is  important  for  both 
VMSA  and  JSAF  to  have  the  same  acoustic  signatures  in  their  tables.  This  is 
not  an  issue  for  the  dipping  sonar  since  all  active  acoustics  are  within  JSAF. 

6.4  “Intercept”  Sonar 

This  federate  is  the  same  federate  described  in  Section  3.3,  however,  in  this  case  it 
will  be  configured  as  a  VMSA  federate  and  subscribe  to  a  single  VMSA  interaction 
which  will  indicate  the  launch  of  a  torpedo.  The  only  VMSA  Launch  interactions  that 
will  exist  in  the  WIB  scenario  will  be  a  result  of  the  submarine  launching  a  torpedo  at 
a  blue  ship.  Thus,  unlike  with  the  RPR  2.0  version,  there  is  no  value  to  filtering  the 
interactions  based  on  their  weapon  type.  It  will  not  be  clear  to  the  blue  ships  which 
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ship  is  being  attacked  or  from  what  direction;  just  that  attack  is  underway  and  to  ‘be 
warned’ . 


6.4.1  FOM  Requirements 

The  sound  federate  will  play  a  torpedo  launch  sound  when  the  VMSA 
ControlMessage.LaunchControl.Launch  is  received.  The  parameters  of  the 
interaction  are  not  relevant  to  this  federate. 
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7.  Overall  FOM  Requirements 


7.1  VMSA  FOM  Subset 

Table  19  summarizes  the  relevant  VMSA  FOM  requirements  for  WIB.  The  publish 
(P)  and  subscribe  (S)  indicators  are  from  the  point  of  view  of  the  VMSA  side  of  the 
bridge  (Tacoma  VMSA  On-ramp). 


Table  19.  VMSA  FOM  Requirements  -  Summarized 


OBJECT 

ATTRIBUTE 

CompositeEntity.Subsurface  (P) 
CompositeEntity.Surface  (S) 

CompositeEntity.Air  (S) 

Name 

Description 

Affiliation 

Role 

Position 

Velocity 

Acceleration 

Orientation 

Orientation  Rate 

DRAIgorithm 

ComponentEntity  (S) 

ComponentName 

Status 

RelativePosition 

RelativeOrientation 

ParentCompositeEntity 

ObjectlnstanceName 

SignalT ask. ActiveT ask. RFT ask. RadarT ask  (S) 

TaskName 

On 

RelativePosition 

SignalPatternReference 

SignalPatternOrientation 

SignalPatternOrientationRate 

SignalPatternDRAIgorithm 

ComponentObjectlnstance  Name 

ParentCompositeEntityObjectlnstanceName 

CentreFrequency 

RadarTask 

ControlMessage.LaunchControl. Launch  (PS) 

InitiatorObjectlnstanceName 

ControlMessagelD 

Plan 

EntityName 
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7.2  RPR  2.0  FOM  Subset 


Table  20  summarizes  the  relevant  RPR  2.0  FOM  requirements  for  WIB.  The  publish 
(P)  and  subscribe  (S)  indicators  are  from  the  point  of  view  of  the  RPR  2.0  side  of  the 
bridge  (Tacoma  RPR  2.0  on-ramp). 


Table  20.  RPR  2.0  FOM  Requirements  -  Summarized 


OBJECT 

ATTRIBUTE 

BaseEntity.  Physical  Entity.  Platform.  Aircraft  (P), 
BaseEntity.PhysicalEntity.  Platform. SurfaceVessel  (P), 
BaseEntity.PhysicalEntity. Munition  (P) 

Entityldentifier 

EntityType 

Spatial 

Forceldentifier 

BaseEntity.PhysicalEntity. Platform. SubmersibleVessel  (S) 

Entityldentifier 

EntityType 

Spatial 

Forceldentifier 

Articulated  ParametersArray 

EmbeddedSystem.EmitterSystem  (P) 

HostObjectldentifier 

RelativePosition 

Entityldentifier 

Emitterlndex 

EmitterFunctionCode 

EmitterType 

EmitterBeam  (P) 

BeamParameterlndex 

BeamAzimuthCenter 

BeamAzimuthSweep 

BeamElevationCenter 

BeamElevationSweep 

BeamFunctionCode 

Beamldentifier 

EffectiveRadiatedPower 

EmissionFrequency 

EmitterSystemldentifier 

Eventldentifier 

FrequencyRange 

PulseRepetitionFrequency 

PulseWidth 

SweepSynch 

EmbeddedSytem.UnderwaterAcoustics.ActiveSonar  (P) 

FunctionCode 

WeaponFire  (PS) 

Eventldentifier 

FireControlSolutionRange 

FireMissionlndex 

FiringLocation 

FiringObjectldentifier 

FuseType 

InitialVelocityVector 

MunitionObjectldentifier 

MunitionType 

QuantityFired 

RateOfFire 

TargetObjectldentifier 

WarheadType 
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8.  The  Next  Step 


The  next  step  of  the  integration  process  for  WIB  is  to  review  the  inputs  from  each 
federate’s  responsible  party  and  to  collectively  agree  on  how  the  RPR  2.0  FOM  will  be 
used  to  support  the  WIB  exercise.  Ideally,  the  RPR  2.0  implementation  of  each 
federate  can  be  realized  without  significant  modifications  to  the  individual  proposed 
plans.  In  designing  this  plan  for  the  VMSA  simulation,  the  RPR  2.0  documentation 
[1]  was  closely  followed  and  considered  to  minimize  potential  conflicts  with  other 
federates. 

Since  the  initial  integration  testing  for  federates  is  scheduled  to  occur  next  month 
(January  2006),  development  of  federates,  bridges,  and  other  software  interfaces  has 
been  forced  to  begin  (and  in  some  cases  end)  without  a  priori  knowledge  of  how  the 
RPR  2.0  FOM  will  be  applied  to  WIB  or  what  data  agreements  will  be  required.  This 
means  that  following  such  decisions,  the  development  that  has  already  occurred  may 
require  re-examination.  Clearly  this  is  not  an  ideal  situation,  but  given  the  restrictive 
timelines,  there  was  no  suitable  alternative.  However,  even  with  the  quickly 
approaching  deadlines,  the  VCS  Group  remains  confident  in  their  ability  to  deliver  a 
VMSA-simulated  submarine  with  passive  sonar  and  ESM  sensors  and  a  torpedo 
launching  capability  that  will  interact  appropriately  with  JSAF  in  a  RPR  2.0 
federation.  It  is  hoped  that  other  responsible  parties  have  similar  confidence  in 
providing  their  own  federate(s)  and  that  in  the  end  a  country-wide  distributed 
simulation  capability  will  be  demonstrated  and  exercised. 


DRDC  Atlantic  TM  2005-273 


25 


9.  References 


1.  Guidance,  Rationale,  and  Interoperability  Manual  for  the  Real-time  Platform  Reference 
Federation  Object  Model  (RPR  FOM)  Version2.0D17v3 ,  Unapproved  Draft,  Simulation 
Interoperability  Standards  Organization,  October  2003. 

2.  Canney,  Shane  A.,  Virtual  Maritime  System  Architecture  Description  Document  Issue 
2.00 ,  Defence  Science  and  Technology  Organization,  Virtual  Maritime  Systems 
Document  Number  00034,  July  2002. 

3.  Gillis,  Allan  D.,  Tacoma  VSMA  to  RPR  2.0  Draft  17  Bridge  User's  Guide  (Draft),  DRDC 
Atlantic  Technical  Memorandum,  TM  2005-222,  2005. 

4.  Enumeration  and  Bit  Encoded  Values  for  Use  with  Protocols  for  Distributed  Interactive 
Simulation  Applications ,  Institute  for  Simulation  and  Training,  Contract  N61339-94-C- 
0080,  May  2003. 

5.  Fullford,  Deb,  Distributed  Interactive  Simulation:  It's  Past,  Present,  and  Future,  MAK 
Technologies,  Proceedings  of  the  1996  Winter  Simulation  Conference,  1996. 

6.  Gillis,  Allan,  Sonar  VMSA  Federate  Version  3.0.0:  User  Guide  and  Technical 
Description  (Draft),  DRDC  Atlantic  Technical  Memorandum,  TM  2005-286,  2005. 

7.  Canney,  Shane  A.,  Constructing  an  Infrastructure  to  Facilitate  Electronic  Support 
Modelling  in  the  Virtual  Ship,  Defence  Science  and  Technology  Organization,  Electronic 
Warfare  Division,  DSTO-TR-1 159,  May  2001. 

8.  IEEE  Standard  for  Distributed  Interactive  Simulation  -  Application  Protocols,  IEEE 
Computer  Society,  Sponsored  by  the  Distributed  Interactive  Simulation  Committee, 
August  1998. 


26 


DRDC  Atlantic  TM  2005-273 


List  of 

symbols/abbreviations/acronyms/initialisms 


AFI 

Agile  FOM  Interface 

C2 

Command  and  Control 

CFMWC 

Canadian  Forces  Maritime  Warfare  Center 

DIS 

Distributed  interactive  Simulation 

DMSO 

Defense  Modeling  and  Simulation  Office 

ERP 

Effective  Radiated  Power 

ESM 

Electronic  Support  Measures 

FOM 

Federation  Object  Model 

HLA 

High  Level  Architecture 

JSAF 

Joint  Semi-Automated  Forces 

MPA 

Maritime  Patrol  Aircraft 

PRF 

Pulse  Repetition  Frequency 

PW 

Pulse  Width 

RCS 

Radar  Cross  Section 

RPR 

Real-time  Platform  Reference 

RTI 

Run  Time  Infrastructure 

TMA 

Target  Motion  Analysis 

VCS 

Virtual  Combat  System 

VMS  A 

Virtual  Maritime  Systems  Architecture 

WIB 

War-in-a-Box 
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